…st helper

- Rename mtls_app_to_app_test.go -> identity_aware_routing_test.go
- Update main test suite: 'App-to-App mTLS Routing' -> 'Identity-Aware Routing'
- Rename registerWithAllowedSources() -> registerWithAccessRules()
- Rename registerWithScopeAndAllowedSources() -> registerWithScopeAndAccessRules()
- Update parameter names: allowedSources -> accessRules
- Update test descriptions: 'mtls_allowed_sources' -> 'access rules'
- Update comments to reflect access-rules terminology

This aligns with the RFC's positioning of the feature as 'identity-aware
routing' with access rules, rather than mTLS-specific 'allowed sources'.

…ction auth

Remove EndpointOrgIDs() and EndpointSpaceIDs() which collected org/space
IDs from all endpoints in a pool. These were used by the deprecated
pre-selection authorization approach.

Post-selection authorization (RFC-compliant) checks org/space boundaries
against the SELECTED endpoint's tags, not against all endpoints in the pool,
making these aggregation methods unnecessary.

Route-registrar is used by BOSH-deployed system components (CC, UAA, etc.)
to register their routes. These system components:
- Don't have CF app identities (no Diego instance identity certs)
- Don't use mTLS domains with access control enforcement
- Are out of scope for the app-to-app identity-aware routing RFC

Only Cloud Controller → Diego → NATS should send access_scope/access_rules
for actual CF app routes. Route-registrar doesn't need these fields.

Devbox is used for local development environment setup but should not
be tracked in the repository. The files remain in the working directory
for developers who use devbox.

routing-api is a local submodule in src/code.cloudfoundry.org/routing-api,
not an external dependency. It should not be listed in go.mod.

This was incorrectly added during rebase conflict resolution.

- Export MakeEndpoint method for test access
- Fix test calls to MakeEndpoint with correct parameters
- Remove unnecessary fmt.Sprintf for string argument

This commit fixes all failing integration tests for the identity-aware
routing feature by addressing three critical issues:

1. mTLS client certificate trust chain issue
   - Tests were creating instance identity certs with a different CA than
     the one configured in GoRouter's mTLS domain settings
   - Added CreateInstanceIdentityCertWithCA() helper that accepts an
     existing CA to ensure proper trust chain
   - Updated all test cases to use the shared mtlsDomainCA

2. Authorization errors returning HTTP 502 instead of 403
   - Added custom ErrorHandler to httputil.ReverseProxy that checks for
     AuthError and returns the appropriate HTTP status code (403)
   - Previously all transport errors defaulted to 502 Bad Gateway

3. Per-endpoint access rules not working correctly
   - Authorization handler was checking pool-level access rules (first
     endpoint only) instead of the selected endpoint's rules
   - Changed to use endpoint.AccessRules to support different backends
     with different authorization requirements on the same route

4. Default-deny not enforced for routes without access rules
   - Changed enforcement logic to apply to all requests with CallerIdentity,
     regardless of AccessScope setting

5. SNI/Host header mismatch in test requests
   - Added newMtlsGetRequest() helper with custom DialTLSContext that
     connects to 127.0.0.1 while preserving hostname for TLS SNI
   - Updated all identity-aware routing tests to use this helper

Test results: 20/20 integration tests passing, 17/17 unit tests passing

This prevents the subscriber's ClosedCB from firing log.Fatal when
NATS is stopped first, which was causing the test process to exit
prematurely and leading to port binding conflicts in parallel test
runs.

The cleanup order is now:
1. Terminate gorouter session
2. Stop NATS server
3. Clean up test files

This matches the fix from upstream PR #555 (commit b2bf830) which
resolved similar issues in router/router_test.go.

Apply comprehensive terminology rebranding from 'access rules' to 'route policies'
across the gorouter codebase to align with Cloud Foundry's existing 'network policies'
convention. This matches the terminology changes from GitHub PR #1438 commit be8d74c1.

Key terminology changes:
- Types: MtlsAccessRulesAuth → MtlsRoutePoliciesAuth
- Functions: evaluateAccessRules() → evaluateRoutePolicies()
- Functions: parseCommaSeparatedSelectors() → parseCommaSeparatedSources()
- Constants: AccessScopeAny/Org/Space → RoutePolicyScopeAny/Org/Space
- Struct fields: AccessScope → RoutePolicyScope, AccessRules → RoutePolicies
- JSON tags: access_scope → route_policy_scope, access_rules → route_policy_sources
- Error messages: route:no_access_rules → route:no_route_policies
- Error messages: route:access_rules → route:route_policies
- Comments: 'access rules' → 'route policies', 'selector' → 'source'

Files modified:
- Core: route/pool.go, mbus/subscriber.go
- Handlers: mtls_route_policies_auth.go (renamed), mtls_pre_auth.go, mtls_scope_auth.go, proxy/proxy.go
- Tests: All corresponding test files updated

All unit tests passing (972 specs total):
- handlers: 360/360 passed
- route: 252/252 passed
- mbus: 8/8 passed (subset)
- proxy: 376/376 passed

Fix struct field alignment in test files to pass CI gofmt validation.

Complete the terminology rebrand by updating integration test helper
functions to use RoutePolicyScope and RoutePolicySources instead of
the old AccessScope and AccessRules field names.

Fixes go vet error: unknown field AccessScope in struct literal

This commit fixes a critical bug where route policies were incorrectly
enforced on ALL routes (including public routes and mTLS routes without
--enforce-route-policies flag), causing 403 Forbidden errors.

Root Cause:
- MtlsRoutePoliciesAuth.Check() only checked CallerIdentity == nil to
  decide whether to skip enforcement
- It did NOT check routePolicyScope (which indicates if enforcement is
  actually enabled for the domain)
- This caused enforcement on routes where it should be skipped

Fix:
- Add routePolicyScope check at the beginning of Check() method
- Only enforce route policies when routePolicyScope != "" (enforcement
  enabled via --enforce-route-policies flag on domain creation)
- This mirrors the pattern already used in MtlsScopeAuth handler

Impact:
- Public routes (non-mTLS domains): No longer incorrectly rejected
- mTLS routes WITHOUT --enforce-route-policies: No longer rejected
- mTLS routes WITH --enforce-route-policies: Still correctly enforced

Test Coverage:
- Added regression test for the specific bug scenario:
  RoutePolicyScope empty + CallerIdentity present
- This test would have caught the bug if it existed originally
- All 18 MtlsRoutePoliciesAuth tests now pass
- Test suite now covers all skip scenario combinations

Files Changed:
- src/code.cloudfoundry.org/gorouter/handlers/mtls_route_policies_auth.go
- src/code.cloudfoundry.org/gorouter/handlers/mtls_route_policies_auth_test.go

HTTP clients that include explicit ports in URLs (e.g., https://app.example.com:443/)
result in Go's http.Request.Host containing the port (app.example.com:443).

Previously, GetMtlsDomainConfig() did not strip the port before matching against
configured mTLS domains (e.g., *.apps.identity), causing:
- Domain matching to fail for requests with explicit ports
- No XFCC header added (fell back to default behavior)
- Identity extraction failure in CallerIdentity
- Pre-auth handler denying requests with 403 and reason "identity-extraction-failed"

This particularly affected Java Spring Boot HTTP clients which construct URLs
with explicit ports by default.

Fix: Use net.SplitHostPort() to strip port before domain matching, ensuring
consistent behavior regardless of whether clients include explicit ports.

Added comprehensive unit tests covering:
- Wildcard domain matching with/without ports
- Exact domain matching with/without ports
- IsMtlsDomain() function with/without ports
- Negative test cases for non-mTLS domains